Inheriting Existing MSP Backups 2024

Published 5 months ago5 min read Redstor MSP...

Inheriting an existing backup from an outgoing MSP will be the joyous topic of today's article.

I will try and give some pointers based on my experience of this process including ways in which you can avoid tension in what can be a volatile process.

As a secondary goal of the main topic, I will also discuss how documentation can help IT consulting services manage and maintain data recovery solutions effectively as it specifically relates to this topic.

While you are here, take a look at some of our other backup resources below that may interest you:

Information architecture and documenting is also an essential aspect of the IT industry whether it be the concerns about backup inheritance discussed here or the steps involved on how to set up a Network attached drive using nas4free so that others on your help desk can set it up from scratch in a time effective fashion . It enables IT consulting advisors to manage and maintain the IT infrastructure of their clients effectively.

We have years of experience in working with service providers to copy write their processes and procedures and there is no area more important to a service provider than how their clients' backup and disaster recovery systems are documented.

Backup Rollout Planning

Hopefully you have some experience already in taking over a client that has an out-going MSP and lived through some of the issues that crop up.

Lack of planning is probably one of the biggest causes of project failure when it comes to inheriting a backup site. The first step is to have a plan of attack. Sit down and come up with a set of steps that you know you need to execute to successfully put in place the new backup solution that your organization is going to provide.

Assuming you already have your plan documented in something like IT Glue or Hudu, planning should ideally start 1 month prior to takeover. My recommendation is that you do not include onboarding client backup solutions into whatever agreement they have signed on to. This is because there are far too many moving parts and it needs to be treated as a standalone backup rollout project.

Backup Pricing Conversation

Clients hate unexpected costs. It is imperative that when signing a new client up to a backup strategy that you have a detailed conversation about the costs involved and what is and what is not included in that price. Have them initial each inclusion and sign the MSA.

I treated the backup agreement as a separate discussion from the Backup onboarding project and kept the costing completely separate. I would make it clear the tasks that we included as well as the tasks that could cause the Back up onboarding process to go over our estimates.

I would always clearly state that while our estimation would be X hours, there was no upper limit to the amount of hours that an onboarding backup project could take due to the number of variables that were unknown to us.

My strategy was always to estimate as best I could and then double the hours estimated. So if I thought it would take 50 hours then I would estimate 100 hours of technical labor to complete the onboarding process. This would also require this to be paid as block hours in advance.

Any remainder can be put towards out of scope work as part of the backup agreement or even general managed service agreement. This takes the pressure of cash flow out of the equation for you and allows you to focus on the job at hand.

The other benefit here is that if a block hour agreement in advance is an issue then it's a strong indicator early on that perhaps you need to re-evaluate if this potential client is going to be worth the effort.

Communication With Client

So you have got the green light and the signatures on the agreement and everything looks like it is going really well. The client has treated you like some sort of shirtless hero arriving on a horse which is weird because you just met these people but you accept you are awesome and put it down to them being intuitive.

This is not the time to allow flattery to lull you into not getting information on this prospective client. A bad client can quite easily cost you a fortune and leave you with such little resources that your other clients will just quietly leave you.

Between sending out the invoice for block time and receiving payment is the perfect time to do some reconnaissance. You should have already asked the client a few questions that help you determine why the relationship with the previous provider has broken down to the point of parting ways.

Changing providers is an expensive evolution. Ask them why they are moving providers. It is a mistake to think that they removed the backup provider because of a technical deficiency. I am yet to meet a service provider that does not think other companies are incompetent and so when a client states it is because of technical incompetence, the incoming provider thinks to themselves “Yep, exactly what I suspected, this MSP is run by turtles”

Be very careful of believing the new client here. You want to, it is really seductive to believe that you are the solution to the problems caused by the soon to be exiled and outgoing numpty.

If a new client uses the lack of technical competence in the form of “they were useless” but does not give specific instances or examples of how they failed technically then that is a serious red flag.

First, most clients do not have the ability to measure a technical person's technical ability, that is why they hire service providers, they do not know the technical work we do. Would it surprise you to know that nearly all client/MSP breakdowns are due to personality conflicts and familiarity breeding contempt rather than anything technical related?

Now if they give a number of examples like “We have had 2 instances in 3 months where they were unable to recover important information” then they may have a good reason but remember, you are only getting half of the story.

Communication With Outgoing Backup Provider

Try and get the chance to talk to the outgoing MSP prior to beginning the project and do this early on. If the client demands you have no contact with them then just explain that contact will be required to facilitate the offboarding process of backups. Take note if they are uncomfortable with this occurring as it is another important piece of information.

None of these behaviors that you witness should be considered proof of anything on their own but when they start adding up, you need to use good judgment here.

If you get to speak with the outgoing MSP and they reply with something along the lines of “We asked them constantly not to save files to the desktops, we undertook training for their staff at our expense because they hire people without appropriate computer knowledge and both of those instances were due to files lost on a desktop we do not believe we were at fault. We offered them a higher level of backup coverage that would include their workstations but they refused the extra cost”

Now you have both sides of the story, who are you siding with? How many times have you had conversations with clients advising them they are taking large risks and put effort into helping them only to have your offer rejected?

Try and speak with both the assigned engineers if possible as well as management if at all possible. There were several times after I started my own MSP that I would know the outgoing MSP and knew they were a solid operation, sometimes they were more evolved and used better tools than we were using at the time. I was able to have direct access to the owner and the 2 times this occurred, they were guys I respected and trusted.

I was able to get good background information on why the relationship had ended and certainly in one of those cases it stopped us moving forward at all as we found the client had lied through their teeth and owed a substantial amount of money to the provider.

The other situation we did go ahead as there had just been a souring of the relationship over time along with a couple of events that could be categorized as bad luck. I overrode my gut feeling with that one and 18 months later certainly regretted that decision.

Communication With Clients Employees

Often communication with the outgoing backup provider will not be great and this is often due to strained relationships between the client and provider so you will be unable to obtain intelligence on the client via that avenue.

The client may have passed the sniff test and given all of the appropriate answers. Door number 3 is the client's staff. Some discrete poking around and discussions with the staff can help establish the viability of the future relationship.

Do they tend to blame every problem on technology and the people that maintain it? Do they appear to have the minimum amount of computer training to hold the position that they do?

Are they friendly and appear to form a cohesive team? Do they seem to absorb the knowledge you are imparting and do they seem to get along with the previous service provider? If they did not get along with them, why not? These are all important points to establish.

De Escalation Of Tense Situations

We all have pretty similar work lives in the managed service industry and the sector has matured a lot so there is now a reasonably standard way of handling things. Stop thinking of the outgoing MSP as the enemy. He is your best friend in this situation in most cases.

If you approach them in a conciliatory way and ignore any initial signs of anger and frustration, you will likely find that their willingness to help you exceeds the need to burn their client. You may also get some good inside information such as the reasons why things broke down.

Handling Payment Disputes

Often when the outgoing MSP is being difficult it is because they have not been paid for work they have undertaken and or are expected to interact with the onboarding team unpaid. I think that would anger most of us.

It is really worth attempting to discuss this situation with the client and attempt to persuade the client to pay any outstanding bills to make it easier to achieve an outcome everyone wants. I realize that is a tall ask.

Alternatively you could approach the MSP and agree to pay them for the offboarding work if you are certain you want to still have this client. It could well be the cheaper option for you to achieve your goals. Of course check with your cyber insurance broker to ensure that this will not cause any issues.

Any hint of a potential client refusing payment to an outgoing MSP should be seen as another big concern. I do not know about anyone else but I pay my bills, I do not look for an excuse to get out of paying them and so I personally look down on those sorts of tactics with very few exceptions.

3rd Party Background Checks

Finally door number 5. There are plenty of third party applications out there that allow you to do background checks on individuals however there are now plenty that will also allow you to investigate companies. You specifically want to look for patterns of legal action being taken over time as well as being taken to court for non payment of bills.

If you do not have access to this type of application or you cannot get a history on legal actions they have taken in the past then speak to your CyberSecurity Insurance broker and the reason I say that is, they will have all manner of risk assessing tools that may not be available to you.

It is as much in their interest as it is in yours to ensure that you are not about to take on the Charles Manson of the client world with 23 legal actions against providers in 10 years.

They may be able to do a very quick check and inform you if the potential client is a risk or not.

1 Month From Backup Migration

Ideally there is a 1 month gap between getting the go ahead and the backup project physically beginning. A perfect world hey! Yeah I realize that in most cases it will probably be less than that.

I wanted a month but would settle for a minimum of 2 weeks, any less than that and I would let the client know it was not going to be possible. I never had a client walk away at that point which just goes to show, if you use firm communication and act as if, there is unlikely going to be any issues.

The reason I preferred 1 month is because it meant I could send the invoice with payment in advance for the 100 hours out immediately and have a 2 week buffer before lifting a finger reducing our risk as the service provider.

I would send the invoice out and if it had not been paid in the first week then I would send an invoice reminder and follow up with a phone call to get things moving explaining the need for it to be paid to begin the backup onboarding project.

I would wait another week so 2 weeks in total and if it had not been paid I would let them know that it had not been paid and that the project would be pushed out by 2 weeks from the date it was paid.

It was a great way to eliminate poor paying clients. Some were legitimate oversites and in most instances that was the case. I had a few that I never heard from again. The beauty of that is I did not waste a single hour of my technical staff's time on people that were going to be difficult to get payment from.

Once you whittle that start time down to 2 weeks then you start to get to a point where the actual work for the onboarding backup project needs to begin and that can overlap with not getting paid. As a service provider you are not taking on the risk because your remote tech staff are having to invest hours on setup and the new client does not yet have skin in the game. I was burnt too many times to ever let that happen again.

Good clients will always make sure they pay promptly.

Backup Offboarding Day

I used to plan the offboarding of a previous backup provider so that it was like an ax falling, minimizing as much as possible the time with which both providers had agents or third party applications communicating at the same time.

If you plan it right then you should be able to use powershell scripting tools via an RMM tool such as Halo remote management to remove old backup agents at the exact same time as each other across all client sites. From that point you are now in control. It was a lot like painting a room, 90% of the work was preparation.

How you plan the timing and what you include in the steps for backup handover exceeds the high level of discussion this article is aimed at but certainly message me if you need a template and I may be able to dig one up.

Conclusion

Inheriting existing MSP backups and or offboarding an ex backup provider is not only a complex task, it also requires good people skills because there are usually hurt feelings and frustration on both sides with yourself in the middle.

The effort spent on overlooking abrasive interactions with both the client and outgoing provider will pay dividends in significantly increasing the chance of a successful backup onboarding project.

Couple that with getting paid up front for the up front work and the chances are quite good that you will end up completing the evolution smoothly.

We have a number of other backup articles specifically related to clients listed below that will provide you with more detailed information on a number of related topics:

https://optimizeddocs.com/blogs/backups/backups-client-index

Our team specializes in strategies for Technology support providers and we assist in improving profit margins through standardization and consistent record keeping strategies, so you can be confident that our content is tailored to your needs.

Please feel free to explore our other articles and click on any that interest you. If you have any questions or would like to learn more about how we can help you with your documentation.